Decoding html pages

Santander

how to decode HTML pages encoded like this:
http://www.long2consulting.com/seein...able/index.htm
Is there script that will do this automatically and generate normal fully
readable HTML?

Santander

Oct 23 '08 #1

Subscribe Post Reply

8853

Bart Van der Donck

Santander wrote:

how to decode HTML pages encoded like this:
http://www.long2consulting.com/seein...able/index.htm
Is there script that will do this automatically and generate normal fully
readable HTML?

It can be decrypted with relatively little effort. Line 5 is the
percent-encoding of (line-ends and intervals added):

<SCRIPT LANGUAGE="JavaScript">

</SCRIPT>

Info:
http://en.wikipedia.org/wiki/Percent-encoding

Function 'hp_d01' takes the square number of the character code when
it's below 128. For a decryption, this operation can be reversed by
taking the square root, eg. Math.sqrt(64).

Hope this helps,

--
Bart

Oct 23 '08 #2

Santander

well, I've decoded the very top part of script:

<SCRIPT LANGUAGE="JavaScript"></SCRIPT>
but it tells me nothing though. How to decode the rest part of page? any
automated tool/script availble?
------------------------

"Santander" <sa*******@comp.lang.javascriptwrote in message
news:49***********************@news.sunsite.dk...

how to decode HTML pages encoded like this:
http://www.long2consulting.com/seein...able/index.htm
Is there script that will do this automatically and generate normal fully
readable HTML?

Oct 23 '08 #3

Gregor Kofler

Santander meinte:

how to decode HTML pages encoded like this:
http://www.long2consulting.com/seein...able/index.htm

Is there script that will do this automatically and generate normal
fully readable HTML?

LOL. Tells me something about both the authors of this page and you as
the upcoming hakk3r...

Just have a look at "generated source" with FF's web developer
extension, or inspect the page with Firebug.
Gregor

Oct 23 '08 #4

Gregor Kofler

Gregor Kofler meinte:

Santander meinte:
>how to decode HTML pages encoded like this:
http://www.long2consulting.com/seein...able/index.htm

Is there script that will do this automatically and generate normal
fully readable HTML?

LOL. Tells me something about both the authors of this page and you as
the upcoming hakk3r...

Forget my above posting. Working with the mentioned tools without the
experience can lead to a complete loss of data and system crashes.
Seriously.

I do have an offer here: Get the full and completely disclosed template
for, say, 40 bucks? Perhaps you're interested in a few more templates?
Bulk discounts are negotiable...

Gregor

Oct 23 '08 #5

Santander

yes, I find this. But how to use this key? Just tried insert that script
into page header section and run, not help, strange.
any ideas? Automated tool encode/ decode?

S.
---------

"Bart Van der Donck" <ba**@nijlen.comwrote in message
news:54**********************************@v56g2000 hsf.googlegroups.com...

Santander wrote:

>how to decode HTML pages encoded like this:
http://www.long2consulting.com/seein...able/index.htm
Is there script that will do this automatically and generate normal fully
readable HTML?

It can be decrypted with relatively little effort. Line 5 is the
percent-encoding of (line-ends and intervals added):

<SCRIPT LANGUAGE="JavaScript">

</SCRIPT>

Info:
http://en.wikipedia.org/wiki/Percent-encoding

Function 'hp_d01' takes the square number of the character code when
it's below 128. For a decryption, this operation can be reversed by
taking the square root, eg. Math.sqrt(64).

Hope this helps,

--
Bart

Oct 23 '08 #6

Santander

any *positive* ideas? if not - no probs.. I already decode 1/2 and even
without your valuable help..

S.
------

"Gregor Kofler" <us****@gregorkofler.atwrote in message
news:Po*************@nntpserver.swip.net...

Gregor Kofler meinte:
>Santander meinte:
>>how to decode HTML pages encoded like this:
http://www.long2consulting.com/seein...able/index.htm
Is there script that will do this automatically and generate normal
fully readable HTML?

LOL. Tells me something about both the authors of this page and you as
the upcoming hakk3r...

Forget my above posting. Working with the mentioned tools without the
experience can lead to a complete loss of data and system crashes.
Seriously.

I do have an offer here: Get the full and completely disclosed template
for, say, 40 bucks? Perhaps you're interested in a few more templates?
Bulk discounts are negotiable...

Gregor

Oct 23 '08 #7

Gregor Kofler

Santander meinte:

any *positive* ideas? if not - no probs.. I already decode 1/2 and even
without your valuable help..

Must be tough, since you've problems perhaps not with reading, but
definitely with *understanding*. Just have a look at the "generated
source" in FF's "web developer extension" (or a similiar tool, Firebug
and I suppose Opera Dragonfly works, too).

Since you are posting with Outlook Express, and are raiding a web site
offering templates for FrontPage and Expression Web, you've probably
never heard of alternatives to IE...

To be even mor constructive: here's the complete source. This time for
free [1]. Make sure to scroll to the bottom...

Gregor
[1]
<html xml:lang="en" xmlns="http://www.w3.org/1999/xhtml" lang="en"><head>


<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252"><script language="JavaScript"></script><script
language="JavaScript"></script><script
language="JavaScript"></script><script
language="JavaScript"></style>');if(navigator.appName.indexOf('Internet
Explorer')!=-1&&(navigator.userAgent.indexOf('MSIE')==-1||document.all.length==0))hp_ok=false;if(document .all)document.write('<link
rel=stylesheet type="text/css"
href="hp_null.css">');//--></script><style type="text/css"
media="print"></style>
<title>Home</title>

<meta name="description" content="website template">
<meta name="keywords" content="website, template, long2 consulting">
<meta name="owner" content="">
<meta name="copyright" content="">

<meta name="author" content="YourNameHere">
<meta name="rating" content="General">
<meta name="revisit-after" content="7 days">
<link rel="stylesheet" type="text/css" href="styles.css">
</head><body><noscript>To display this page you need a browser with
JavaScript support.</noscript><script language="JavaScript"></script>
<div id="wrapper">
<table>
<tbody><tr>
<td id="header1"><div class="headercontent">


Company Name
</div></td>
</tr>
<tr>
<td id="topnav">

<div class="topnavlinks">
<a href="index.htm">Home</a>
<a href="faqs.htm">FAQs</a>

<a href="store.htm">Our Store</a>
<a href="layout1.htm">Layout 1</a>
<a href="layout2.htm">Layout 2</a>
<a href="layout3.htm">Layout 3</a>
<a href="gettingstarted.htm">Getting Started</a>
</div>

</td>
</tr>
</tbody></table>
<table class="bodytable">
<tbody><tr>

<td id="body2"><div class="body2content">

<div class="menuheader1"><a href="#">Main Menu</a></div>
<div class="sidelinks">
<a href="index.htm">Home</a>

<a href="faqs.htm">FAQs</a>
<a href="services.htm">Services</a>
<a href="contactus.htm">Contact Us</a>
</div>

<div class="menuheader1"><a href="store">Our Store</a></div>
<div class="sidelinks">
<a href="product1.htm">Product 1</a>

</div>

<div class="menuheader1"><a href="#">Layouts</a></div>
<div class="sidelinks">
<a href="layout1.htm">Layout 1</a>
<a href="layout2.htm">Layout 2</a>
<a href="layout3.htm">Layout 3</a>
</div>

<div class="menuheader1"><a href="#">Template Info</a></div>

<div class="sidelinks">
<a href="gettingstarted.htm">Getting Started</a>
<a href="typography.htm">Typography</a>
</div>
</div>
</td>
<td id="body1"><div class="body1content">
<h2>This template features...</h2>
<ul>

<li>A <b>starter web template</bto help you create
a new web site. You may easily add your own content
and more pages.</li>
<li><b>Designed for 1024 X 768.
Three layouts - 1, 2, and 3 columns.</b></li>
<li><b>Table-based layout</bfor easy use in
FrontPage 2002 and 2003. This template can also be
used with Expression Web.</li>
<li><b>Include pages</bare used for company name,
navigation links, news, and copyright for your
editing convenience.</li>

<li>Tested in recent browsers: Internet Explorer 6,
Netscape 7+, Opera 9, and FireFox.</li>
<li><b>Validated</bXHTML 1.0 strict, CSS. Priority 1 and 2
WCAG 1.0 and Section 508 accessible.</li>
</ul>
<h2>Cascading Style Sheets</h2>
<p>This template uses tables and CSS for the layout. Because the
FrontPage "design view" is not as sophisticated at displaying CSS
properly, the heading fonts will seem very large. This
can be frustrating if you are used to getting a good "preview"
of what your site looks like, but you'll find that it is almost
just as easy to keep previewing your site in a browser as you
make changes. You will still be able to edit your text and add
content as you normally would; after you save, go to File >
Preview in Browser to view your site in a browser and make sure
that it really looks as it should.</p>

<p>Also, occasionally FrontPage's Normal/Design view may "lose" the
formatting. When this happens, just press "F5" to refresh the view and
the styles will return.</p>

</div>
</td>
</tr>
</tbody></table>
<table>
<tbody><tr>
<td id="footer"><div class="footercontent">


¿ 20xx <Company Name> All Rights Reserved.
<br><span class="tiny">Design by <a
href="http://www.long2consulting.com/">Long<sup>2</sup>
Consulting</a></span>
</div></td>
</tr>
</tbody></table>
</div>
</body></html>

Oct 23 '08 #8

Dr J R Stockton

In comp.lang.javascript message <54ad6fa4-90bb-40f6-9334-dabcd75f4614@v5
6g2000hsf.googlegroups.com>, Thu, 23 Oct 2008 07:37:12, Bart Van der
Donck <ba**@nijlen.composted:

c=s.charCodeAt(i);
if (c<128)
c=c^2;
os+=String.fromCharCode(c);

>Function 'hp_d01' takes the square number of the character code when
it's below 128.

! c=c^2 squares? I thought it did 32-bit bitwise XOR.

--
(c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/- FAQqish topics, acronyms & links;
Astro stuff via astron-1.htm, gravity0.htm ; quotings.htm, pascal.htm, etc.
No Encoding. Quotes before replies. Snip well. Write clearly. Don't Mail News.

Oct 23 '08 #9

Spamless

On 2008-10-23, Santander <sa*******@comp.lang.javascriptwrote:

how to decode HTML pages encoded like this:
http://www.long2consulting.com/seein...able/index.htm
Is there script that will do this automatically and generate normal fully
readable HTML?

I loaded into vim, piped the first line through an "unescape" script
to get the definition of the decoding function, hp_d01(.), changed the
document.write to print (to pipe through a javascript interpreter whose
output is given by "print(.)") and piped it through the interpreter.

The top part is more Javascript when decoded. The trick I use to reformat
that is to wrap it in:

function mycrap(){
... the javascript ...
};print(mycrap.toString())

since the interpreter I use (the firefox spider monkey) reformats and
neatens things. The result is something I often used to see on spamvertized
pages to "protect them". The first section "protects" the page, defining various
functions and assigning them to onmousedown, oncontextmenu, etc. events so that
it controls what you see when you try to examine the page. The functions
simply block you from doing things. For example, note the
document.URL.substring(0, 4) == "file"
section below. If you make a copy of the file and attempt to load it
in your browser (a local copy will be accessed with a "file://" URL)
you get nothing
window.location = "about:blank"

The decoding is not hard (I have seen code using arguments.callee.toString()
along with the referrer and page URL as part of the decoding key and others
on UTF8 web pages where one had to use a UTF8 locale (or something like
uni2ascii, a utility which can convert UTF8 into \u#### escaped unicode
which javascript can handle without a browser) and as I said, I have seen
this used on spamvertized sites, but this appears not to be one.
The second part decodes to HTML, a sample page (as another has displayed).
The decoded and reformatted top section is
==========================================

function hp_dn(a) {
return false;
}
function hp_cm() {
alert("This page has been protected. Preview only.");
return false;
}
function hp_de(e) {
return e.target.tagName != null &&
e.target.tagName.search("^(INPUT|TEXTAREA|BUTTON|S ELECT)$") != -1;
}
function hp_md(e) {
mac = navigator.userAgent.indexOf("Mac") != -1;
if (document.all) {
if (event.button == 2 ||
mac && (event.ctrlKey || event.keyCode == 91)) {
alert("This page has been protected. Preview only.");
return false;
}
} else {
if (e.which == 3 || mac && (e.modifiers == 2 || e.ctrlKey)) {
alert("This page has been protected. Preview only.");
return false;
} else if (e.which == 1) {
window.captureEvents(Event.MOUSEMOVE);
window.onmousemove = hp_dn;
}
}
}
function hp_mu(e) {
if (e.which == 1) {
window.releaseEvents(Event.MOUSEMOVE);
window.onmousemove = null;
}
}

if (navigator.appName.indexOf("Internet Explorer") == -1 ||
navigator.userAgent.indexOf("MSIE") != -1 &&
document.all.length != 0) {
if (document.all) {
mac = navigator.userAgent.indexOf("Mac") != -1;
version = parseFloat("0" + navigator.userAgent.substr(navigator.userAgent.ind exOf("MSIE") + 5), 10);
if (!mac && version 4) {
document.oncontextmenu = hp_cm;
} else {
document.onmousedown = hp_md;
document.onkeydown = hp_md;
}
document.onselectstart = hp_dn;
} else if (document.layers) {
window.captureEvents(Event.MOUSEDOWN | Event.modifiers | Event.KEYDOWN | Event.MOUSEUP);
window.onmousedown = hp_md;
window.onkeydown = hp_md;
window.onmouseup = hp_mu;
} else if (document.getElementById && !document.all) {
document.oncontextmenu = hp_cm;
document.onmousedown = hp_de;
}
}
if (document.URL.substring(0, 4) == "file") {
hp_ok = false;
window.location = "about:blank";
}

function hp_dp1() {
for (i = 0; i < document.all.length; i++) {
if (document.all[i].style.visibility != "hidden") {
document.all[i].style.visibility = "hidden";
document.all[i].id = "hp_id";
}
}
}
function hp_dp2() {
for (i = 0; i < document.all.length; i++) {
if (document.all[i].id == "hp_id") {
document.all[i].style.visibility = "";
}
}
}

window.onbeforeprint = hp_dp1;
window.onafterprint = hp_dp2;
document.write("<style type=\"text/css\" media=\"print\"></style>");
if (navigator.appName.indexOf("Internet Explorer") != -1 &&
(navigator.userAgent.indexOf("MSIE") == -1 ||
document.all.length == 0)) {
hp_ok = false;
}
if (document.all) {
document.write("<link rel=stylesheet type=\"text/css\" href=\"hp_null.css\">");
}

Oct 24 '08 #10

Santander

Thanks for tips, this make things more clear.

Santander
-------------
"Gregor Kofler" <us****@gregorkofler.atwrote in message
news:jZ*************@nntpserver.swip.net...

Santander meinte:
>any *positive* ideas? if not - no probs.. I already decode 1/2 and even
without your valuable help..

Must be tough, since you've problems perhaps not with reading, but
definitely with *understanding*. Just have a look at the "generated
source" in FF's "web developer extension" (or a similiar tool, Firebug and
I suppose Opera Dragonfly works, too).

Since you are posting with Outlook Express, and are raiding a web site
offering templates for FrontPage and Expression Web, you've probably never
heard of alternatives to IE...

To be even mor constructive: here's the complete source. This time for
free [1]. Make sure to scroll to the bottom...

Gregor
[1]
<html xml:lang="en" xmlns="http://www.w3.org/1999/xhtml" lang="en"><head>


<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252"><script language="JavaScript"></script><script
language="JavaScript"></script><script
language="JavaScript"></script><script
language="JavaScript"></style>');if(navigator.appName.indexOf('Internet
Explorer')!=-1&&(navigator.userAgent.indexOf('MSIE')==-1||document.all.length==0))hp_ok=false;if(document .all)document.write('<link
rel=stylesheet type="text/css" href="hp_null.css">');//--></script><style
type="text/css" media="print"></style>
<title>Home</title>

<meta name="description" content="website template">
<meta name="keywords" content="website, template, long2 consulting">
<meta name="owner" content="">
<meta name="copyright" content="">

<meta name="author" content="YourNameHere">
<meta name="rating" content="General">
<meta name="revisit-after" content="7 days">
<link rel="stylesheet" type="text/css" href="styles.css">
</head><body><noscript>To display this page you need a browser with
JavaScript support.</noscript><script language="JavaScript"></script>
<div id="wrapper">
<table>
<tbody><tr>
<td id="header1"><div class="headercontent">


Company Name
</div></td>
</tr>
<tr>
<td id="topnav">

<div class="topnavlinks">
<a href="index.htm">Home</a>
<a href="faqs.htm">FAQs</a>

<a href="store.htm">Our Store</a>
<a href="layout1.htm">Layout 1</a>
<a href="layout2.htm">Layout 2</a>
<a href="layout3.htm">Layout 3</a>
<a href="gettingstarted.htm">Getting Started</a>
</div>

</td>
</tr>
</tbody></table>
<table class="bodytable">
<tbody><tr>

<td id="body2"><div class="body2content">

<div class="menuheader1"><a href="#">Main Menu</a></div>
<div class="sidelinks">
<a href="index.htm">Home</a>

<a href="faqs.htm">FAQs</a>
<a href="services.htm">Services</a>
<a href="contactus.htm">Contact Us</a>
</div>

<div class="menuheader1"><a href="store">Our Store</a></div>
<div class="sidelinks">
<a href="product1.htm">Product 1</a>

</div>

<div class="menuheader1"><a href="#">Layouts</a></div>
<div class="sidelinks">
<a href="layout1.htm">Layout 1</a>
<a href="layout2.htm">Layout 2</a>
<a href="layout3.htm">Layout 3</a>
</div>
<div class="menuheader1"><a href="#">Template Info</a></div>

<div class="sidelinks">
<a href="gettingstarted.htm">Getting Started</a>
<a href="typography.htm">Typography</a>
</div>
</div>
</td>
<td id="body1"><div class="body1content">
<h2>This template features...</h2>
<ul>

<li>A <b>starter web template</bto help you create
a new web site. You may easily add your own content
and more pages.</li>
<li><b>Designed for 1024 X 768.
Three layouts - 1, 2, and 3 columns.</b></li>
<li><b>Table-based layout</bfor easy use in
FrontPage 2002 and 2003. This template can also be
used with Expression Web.</li>
<li><b>Include pages</bare used for company name,
navigation links, news, and copyright for your
editing convenience.</li>

<li>Tested in recent browsers: Internet Explorer 6,
Netscape 7+, Opera 9, and FireFox.</li>
<li><b>Validated</bXHTML 1.0 strict, CSS. Priority 1 and 2
WCAG 1.0 and Section 508 accessible.</li>
</ul>
<h2>Cascading Style Sheets</h2>
<p>This template uses tables and CSS for the layout. Because the
FrontPage "design view" is not as sophisticated at displaying CSS
properly, the heading fonts will seem very large. This
can be frustrating if you are used to getting a good "preview"
of what your site looks like, but you'll find that it is almost
just as easy to keep previewing your site in a browser as you
make changes. You will still be able to edit your text and add
content as you normally would; after you save, go to File >
Preview in Browser to view your site in a browser and make sure
that it really looks as it should.</p>

<p>Also, occasionally FrontPage's Normal/Design view may "lose" the
formatting. When this happens, just press "F5" to refresh the view and
the styles will return.</p>

</div>
</td>
</tr>
</tbody></table>
<table>
<tbody><tr>
<td id="footer"><div class="footercontent">


¿ 20xx <Company Name> All Rights Reserved.
<br><span class="tiny">Design by <a
href="http://www.long2consulting.com/">Long<sup>2</sup>
Consulting</a></span>
</div></td>
</tr>
</tbody></table>
</div>
</body></html>

Oct 24 '08 #11

Santander

thanks for analysis. Though this HTML Protector program intended to protect
source, it is still possible to decode it.
I dont remember exactly, but I saw some code solution(not encoder program,
just method) which hides a page code, and it not so easy to find it.

Santander
------------
"Spamless" <Sp******@Nil.nilwrote in message
news:49***********************@news.thorn.net...

On 2008-10-23, Santander <sa*******@comp.lang.javascriptwrote:
>how to decode HTML pages encoded like this:
http://www.long2consulting.com/seein...able/index.htm
Is there script that will do this automatically and generate normal fully
readable HTML?

I loaded into vim, piped the first line through an "unescape" script
to get the definition of the decoding function, hp_d01(.), changed the
document.write to print (to pipe through a javascript interpreter whose
output is given by "print(.)") and piped it through the interpreter.

The top part is more Javascript when decoded. The trick I use to reformat
that is to wrap it in:

function mycrap(){
... the javascript ...
};print(mycrap.toString())

since the interpreter I use (the firefox spider monkey) reformats and
neatens things. The result is something I often used to see on
spamvertized
pages to "protect them". The first section "protects" the page, defining
various
functions and assigning them to onmousedown, oncontextmenu, etc. events so
that
it controls what you see when you try to examine the page. The functions
simply block you from doing things. For example, note the
document.URL.substring(0, 4) == "file"
section below. If you make a copy of the file and attempt to load it
in your browser (a local copy will be accessed with a "file://" URL)
you get nothing
window.location = "about:blank"

The decoding is not hard (I have seen code using
arguments.callee.toString()
along with the referrer and page URL as part of the decoding key and
others
on UTF8 web pages where one had to use a UTF8 locale (or something like
uni2ascii, a utility which can convert UTF8 into \u#### escaped unicode
which javascript can handle without a browser) and as I said, I have seen
this used on spamvertized sites, but this appears not to be one.
The second part decodes to HTML, a sample page (as another has displayed).
The decoded and reformatted top section is
==========================================

function hp_dn(a) {
return false;
}
function hp_cm() {
alert("This page has been protected. Preview only.");
return false;
}
function hp_de(e) {
return e.target.tagName != null &&
e.target.tagName.search("^(INPUT|TEXTAREA|BUTTON|S ELECT)$") != -1;
}
function hp_md(e) {
mac = navigator.userAgent.indexOf("Mac") != -1;
if (document.all) {
if (event.button == 2 ||
mac && (event.ctrlKey || event.keyCode == 91)) {
alert("This page has been protected. Preview only.");
return false;
}
} else {
if (e.which == 3 || mac && (e.modifiers == 2 || e.ctrlKey)) {
alert("This page has been protected. Preview only.");
return false;
} else if (e.which == 1) {
window.captureEvents(Event.MOUSEMOVE);
window.onmousemove = hp_dn;
}
}
}
function hp_mu(e) {
if (e.which == 1) {
window.releaseEvents(Event.MOUSEMOVE);
window.onmousemove = null;
}
}

if (navigator.appName.indexOf("Internet Explorer") == -1 ||
navigator.userAgent.indexOf("MSIE") != -1 &&
document.all.length != 0) {
if (document.all) {
mac = navigator.userAgent.indexOf("Mac") != -1;
version = parseFloat("0" +
navigator.userAgent.substr(navigator.userAgent.ind exOf("MSIE") + 5), 10);
if (!mac && version 4) {
document.oncontextmenu = hp_cm;
} else {
document.onmousedown = hp_md;
document.onkeydown = hp_md;
}
document.onselectstart = hp_dn;
} else if (document.layers) {
window.captureEvents(Event.MOUSEDOWN | Event.modifiers |
Event.KEYDOWN | Event.MOUSEUP);
window.onmousedown = hp_md;
window.onkeydown = hp_md;
window.onmouseup = hp_mu;
} else if (document.getElementById && !document.all) {
document.oncontextmenu = hp_cm;
document.onmousedown = hp_de;
}
}
if (document.URL.substring(0, 4) == "file") {
hp_ok = false;
window.location = "about:blank";
}

function hp_dp1() {
for (i = 0; i < document.all.length; i++) {
if (document.all[i].style.visibility != "hidden") {
document.all[i].style.visibility = "hidden";
document.all[i].id = "hp_id";
}
}
}
function hp_dp2() {
for (i = 0; i < document.all.length; i++) {
if (document.all[i].id == "hp_id") {
document.all[i].style.visibility = "";
}
}
}

window.onbeforeprint = hp_dp1;
window.onafterprint = hp_dp2;
document.write("<style type=\"text/css\"
media=\"print\"></style>");
if (navigator.appName.indexOf("Internet Explorer") != -1 &&
(navigator.userAgent.indexOf("MSIE") == -1 ||
document.all.length == 0)) {
hp_ok = false;
}
if (document.all) {
document.write("<link rel=stylesheet type=\"text/css\"
href=\"hp_null.css\">");
}

Oct 24 '08 #12

Gregor Kofler

Santander meinte:

thanks for analysis. Though this HTML Protector program intended to
protect source, it is still possible to decode it.

It's Snake Oil. Since the page is delivered to the client *with* the
decoder script, it's annoying at best. Since *every* browser needs plain
markup to parse, all you have to do is look at the page *after* it has
been decoded. That's what Firebug or the Web Developer Extension do.

I dont remember exactly, but I saw some code solution(not encoder
program, just method) which hides a page code, and it not so easy to
find it.

Shrug... It's pointless. There just one 100% safe method: Don't publish
your pages. Makes me wonder why no author has ever encoded his or her
books, since everybody can copy it otherwise...

Gregor

Oct 24 '08 #13

Conrad Lender

On 2008-10-24 16:25, Gregor Kofler wrote:

Shrug... It's pointless. There just one 100% safe method: Don't publish
your pages. Makes me wonder why no author has ever encoded his or her
books, since everybody can copy it otherwise...

Some artists did encrypt and publish their work...
http://en.wikipedia.org/wiki/Kryptos
- Conrad

Oct 24 '08 #14

Santander

just one method for javascript:
http://code.google.com/p/turbojs/wiki/ClosedSourceJS

(I am not fully understand how it works and it requires a few dummy js files
for few javascripts)

Santander
-------------

"Gregor Kofler" <us****@gregorkofler.atwrote in message
news:rV*************@nntpserver.swip.net...

Santander meinte:
>thanks for analysis. Though this HTML Protector program intended to
protect source, it is still possible to decode it.

It's Snake Oil. Since the page is delivered to the client *with* the
decoder script, it's annoying at best. Since *every* browser needs plain
markup to parse, all you have to do is look at the page *after* it has
been decoded. That's what Firebug or the Web Developer Extension do.

>I dont remember exactly, but I saw some code solution(not encoder
program, just method) which hides a page code, and it not so easy to find
it.

Shrug... It's pointless. There just one 100% safe method: Don't publish
your pages. Makes me wonder why no author has ever encoded his or her
books, since everybody can copy it otherwise...

Gregor

Oct 24 '08 #15

Gregor Kofler

Santander meinte:

just one method for javascript:
http://code.google.com/p/turbojs/wiki/ClosedSourceJS

Are we talking about JS now?

(I am not fully understand how it works and it requires a few dummy js
files for few javascripts)

You can obfuscate the JS. That's pretty common, though I have yet to
come across some JS really worth "protecting"...

Gregor

Oct 24 '08 #16

Spamless

On 2008-10-24, Santander <sa*******@comp.lang.javascriptwrote:

just one method for javascript:
http://code.google.com/p/turbojs/wiki/ClosedSourceJS

(I am not fully understand how it works and it requires a few dummy js files
for few javascripts)

That isn't a javascript trick, but php blocking of access to the file.
It is a server side trick to prevent one from simply accessing the
*.js file - it has to be loaded by a "proper" page.

It instructs the server to use PHP code on the server when handling
Javascript files (they can have included PHP code) and you put on
your page is (at the end, after its HTML code) an inclusion of a
dummy.js. You use a PHP header script to include the real (protected)
javascript (well, that could be in your index.html file if the server
is set to allow PHP code in html pages).

The dummy.js file is just to protect your file if someone tries to get
it immediately after loading the page without closing the session.
The actual code you want used is in closedsource.js which has PHP code
in it. The server checks to see how it is accessed (the $_SESSION
variable) and either returns the real Javascript OR an error message.
When the page (index.php) is loaded it loads the PHP header script
(the PHP section) which writes to the page you see the inclusion
of the closedsource.js file (the real. but protected, javascript)
AND sets the $_SESSION variable (in the example) to "show".
THAT writes the part of the page which has the inclusion of the
actual file (closesource.js) and your browser goes to get it.

The session is still set to "show" so the server gets the real
code (closedsource.js) and runs the PHP code in it which decides
which portion (the real code or the ERROR message) and if you were
going through the index.php page, it gives you the real Javascript.
If you just try to get the closedsource.js file WITHOUT using index.php
then $_SESSION is not set to "show" so you get the error message
(nothing).

All that works *without* the dummy.js at the bottom of you index.php
page (which is where the
[script type="text/javascript" src="js/dummy.js"][/script]
goes).

What is that dummy.js for? Suppose you browse to the site. You get
the page. Examine the page and see the header which was added by
the php header script (the load of closedsource.js) and WITHOUT
CLOSING THE SESSION just try to get closedsource.js.

You could (since the session variable has been set to "show" when you
loaded index.php which loaded the PHP page-header script which set it).
The dummy.js is just there to prevent that (once you get the page with
the real Javascript, you later load dummy.js which has PHP code to
unset the $_SESSION value so that attempts to get closedsourec.js
only get the portion of it, the error section, that the PHP script
which sends you the page will then let you have).

The idea is ONLY to send the Javascript when accessed from index.php.

How can one get it? Use a packet capture programme and go to the site.
You capture the file as it is loaded by the browser from the page.
Or examine you browser's cache after getting the page (it should be
there).

It does make it impossible just to go and get the *.js file without
using index.php to set the server side $_SESSION variable properly.

Oct 24 '08 #17

Thomas 'PointedEars' Lahn

Spamless wrote:

On 2008-10-24, Santander <sa*******@comp.lang.javascriptwrote:
>just one method for javascript:
http://code.google.com/p/turbojs/wiki/ClosedSourceJS

(I am not fully understand how it works and it requires a few dummy js files
for few javascripts)

That isn't a javascript trick, but php blocking of access to the file.
It is a server side trick to prevent one from simply accessing the
*.js file - it has to be loaded by a "proper" page. [...]

Nonsense. You are making the false assumption that accessing the generated
source code requires another request. It doesn't. One does not even need
Firebug to see it, although it helps.

Besides, generating syntactically invalid source code may cause error
messages and cause other scripts to not work as well.

And your From header needs fixing.
PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee

Oct 24 '08 #18

Santander

what header "fixing" you keep in mind?? I really don't understand.

S.
---------
"Thomas 'PointedEars' Lahn" <Po*********@web.dewrote in message
news:49**************@PointedEars.de...

And your From header needs fixing.
PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee

Oct 24 '08 #19

Spamless

On 2008-10-24, Thomas 'PointedEars' Lahn <Po*********@web.dewrote:

Spamless wrote:
>On 2008-10-24, Santander <sa*******@comp.lang.javascriptwrote:
>>just one method for javascript:
http://code.google.com/p/turbojs/wiki/ClosedSourceJS

(I am not fully understand how it works and it requires a few dummy js files
for few javascripts)

That isn't a javascript trick, but php blocking of access to the file.
It is a server side trick to prevent one from simply accessing the
*.js file - it has to be loaded by a "proper" page. [...]

Nonsense. You are making the false assumption that accessing the generated
source code requires another request. It doesn't. One does not even need
Firebug to see it, although it helps.

That is why the dummy.js file is at the end to unset the session state
allowing one to get the "protected Javascript" (it would be pointless to
block it for everything for then it could not be gotten the first time) when
the page is started then unsetting the server side session variable.

Get the proper page (the server sets its own session information which your
browser never sees) - try to get the protected Javascript and the server,
seeing the session variable properly set, gives it to you. The page loads
and your browser requests the dummy.js file (why not call it "unset.js"?)
which, as the PHP engine parses it unsets the server-side session variable.

Try to get the javascript page without the server having a properly set
session variable and the server sends you syntactically correct javascript,
but a different section (the error section, or perhaps totally different
code) from the file on the server - totally different material.

Besides, generating syntactically invalid source code may cause error
messages and cause other scripts to not work as well.

There is no syntactically invalid source code. The PHP engine examines
the *.js file and only sends to the browser the javascript section (one's
browser never sees the <?... sections which are handled by the PHP engine
and used to determine which section of syntactically correct code is sent -
the Javascript file at http://code.google.com/p/turbojs/wiki/ClosedSourceJS
includes some "<? ... ?>" sections. Those are handled by the PHP engine
which decides which javascript section to send. You never get that file
from the server (the raw source displayed for the closedsource.js file
in the example) - the server sends part of it; either the syntactically
correct first part or the syntactically correct second part - but what
you get depends upon the server side session variable which is only
properly set when you get the "proper" starting page. The raw
closedsource.js file is not "correct" javascript, but is "correct"
PHP/Javascript to be handled not by your browser, but the PHP engine
which sends you just one of the Javascript sections. But which?

Don't load the javascript section at
http://code.google.com/p/turbojs/wiki/ClosedSourceJS
into your browser. Load it into a PHP engine with different settings of the
session state to have that engine return different sections of "correct"
javascript.

The "proper page" DOES get the code. Viewing the code in firebug should
work. wget with a recursive get (set to get the javascript) should work too.
All it does is stop a simple attempt to get the javascript file (well, the
php session will send you something, the other section) directly (without
getting the "proper page" which causes the server to set its own, invisible
to the browser/client, server-side variable to allow access for the current
session).

Some sites were known to deep link into others, getting data pages
without showing the sites' doorway pages with their ads. There are various
tricks to force one to go through a certain page. Examining the referrer
header is one (but the browser/client gets to see that and using curl,
for example, one can set that manually to get a page which should require
first viewing an ad page used as the referrer). This is another such method,
using a server side, invisible to the browser, session variable.

Oct 24 '08 #20

Thomas 'PointedEars' Lahn

Spamless wrote:

Thomas 'PointedEars' Lahn wrote:
>Spamless wrote:
>>On 2008-10-24, Santander <sa*******@comp.lang.javascriptwrote:
just one method for javascript:
http://code.google.com/p/turbojs/wiki/ClosedSourceJS

(I am not fully understand how it works and it requires a few dummy js files
for few javascripts)
That isn't a javascript trick, but php blocking of access to the file.
It is a server side trick to prevent one from simply accessing the
*.js file - it has to be loaded by a "proper" page. [...]
Nonsense. You are making the false assumption that accessing the generated
source code requires another request. It doesn't. One does not even need
Firebug to see it, although it helps.

That is why the dummy.js file is at the end to unset the session state
allowing one to get the "protected Javascript" (it would be pointless to
block it for everything for then it could not be gotten the first time) when
the page is started then unsetting the server side session variable. [...]

The state of the server-side session does not matter at all when (*not* if)
no further request is necessary to get at the code.

And your From header value still constitutes a violation of Internet
standards and a disregard of Netiquette.
Score adjusted; F'up2 poster (not that I expect you to honor that request)

PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16

Oct 24 '08 #21

Spamless

On 2008-10-24, Thomas 'PointedEars' Lahn <Po*********@web.dewrote:

Spamless wrote:
>Thomas 'PointedEars' Lahn wrote:
>>Spamless wrote:
On 2008-10-24, Santander <sa*******@comp.lang.javascriptwrote:
just one method for javascript:
http://code.google.com/p/turbojs/wiki/ClosedSourceJS
>
(I am not fully understand how it works and it requires a few dummy js files
for few javascripts)
That isn't a javascript trick, but php blocking of access to the file.
It is a server side trick to prevent one from simply accessing the
*.js file - it has to be loaded by a "proper" page. [...]
Nonsense. You are making the false assumption that accessing the generated
source code requires another request. It doesn't. One does not even need
Firebug to see it, although it helps.

That is why the dummy.js file is at the end to unset the session state
allowing one to get the "protected Javascript" (it would be pointless to
block it for everything for then it could not be gotten the first time) when
the page is started then unsetting the server side session variable. [...]

The state of the server-side session does not matter at all when (*not* if)
no further request is necessary to get at the code.

Send a request for index.html and you do NOT get the (client side) included
Javascript modules. Another GET request is required. If, somehow, when your
browser sets a
GET /index.php HTTP/1.1
Host: somesite.com
back comes the index.php *and* the (client side) included Javascript file,
then you have a magic browser.

On the other hand, with HTTP 1.1 and "Keep-alive" one does not need a new
TCP stream, that is true, on the other hand a GET request for a new page
will cause another call to the PHP engine to parse the new file.

On the fourth hand, a site could be set up so that the index.php file has
a server side, PHP inclusion of the code so that the PHP engine puts the
actual Javascript code on the index.php page rather than a client side
inclusion
[script type="text/javascript" src="js/closedsource.js"][/script]
as is used here (requiring a new GET request).

The page does not include the code on the server side (it could have
used PHP code to write the contents of some javascript file to the
page itself before sending out the HTML page, with the Javascript on
it rather than write out a [script src=...] tag).

It doesn't. It sends HTML code to have the browser load the *js file
separately. That requires another GET request.

Look ... I didn't write it. Send a note to google telling them that their
programmers are incompetent. Go to
http://code.google.com/p/turbojs/wiki/ClosedSourceJS
and use the link on the bottom to add a comment on how wrong their code is.

Oct 24 '08 #22

Spamless

On 2008-10-24, Spamless <Sp******@Nil.nilwrote:

On 2008-10-24, Santander <sa*******@comp.lang.javascriptwrote:
>just one method for javascript:
http://code.google.com/p/turbojs/wiki/ClosedSourceJS

(I am not fully understand how it works and it requires a few dummy js files
for few javascripts)

That isn't a javascript trick, but php blocking of access to the file.
It is a server side trick to prevent one from simply accessing the
*.js file - it has to be loaded by a "proper" page.

Let me write up something in a bit more detail (as this is not Javascript
but PHP) to indicate what the google example shows.

It is *not* Javascript one can use on one's pages. It is a PHP method one
can use on a server with support for embedded PHP code.

To get around the stateless nature of HTML one can associate a web session
with a server side state saved in some variable, an array, say $_SESSION. To
recognize that a visitor is getting a new page in this same web session one
may set a cookie, say PHPSESSID, to a random variable with short TTL (or set
as a session cookie) (reset and update the TTL as other pages are loaded).
The session variable, an associative array (hash) or object may have
readable and writeable values associated to keys or properties.

Using PHP, one can set the web server NOT to send off the file index.html
when a request for index.html arrives, but instead send the index.html page
to the PHP engine along with the session data/variable/object/array and let
that programme return data to the web server which passes it along to the
visitor's browser as the content returned for the request for "index.html."
In that case, the index.html file need not be pure HTML but has to be
something the PHP engine understands and can use to create valid HTML to
pass along to the web server to pass along to the visitor.

For example, the PHP engine might check for a variable named image_count in
the session data. If not there, set it to zero and add it to the session
data. Next, return as the first part of the HTML code it generates an
[img src=...] tag to display the first banner if image_count is 0, the
second banner if image_count is 1, ... the fifth banner if image_count is 4.
Have it check image_count and if it is zero write out the HTML content for
the first advertisement, if it is one write out the HTML content for the
second ad, etc. and finally increase image_count by 1 mod 5.

If you visit the site you see the first banner and ad. Reload the same page
and see the second. Reload the same page and see the third, etc. You get
different results sending the exact same request data to the same server for
the same page/URL (but never see the original, unchanging "raw" file).

You never see the raw index.html *file* with its embedded PHP code but only
the HTML code that the PHP engine produces *from* the raw html code and that
returned HTML code depends on the current state/session data. This is all
done server side and the visitor does not see the server-side state data
which determines which page he/she gets.

Since this is no longer a stateless connection, one can use the state data
in the session variables/session array/session object to change responses or
access depending upon the state. The use of PHP and tracking the
session/state to allow or block access to a (in this case Javascript) file
is what the example at google provides.

The page at http://code.google.com/p/turbojs/wiki/ClosedSourceJS shows a way
to block access to a Javascript file depending on the state and how to set
and unset state on a page.

To block access to a Javascript file except when a page using it is loading
one can set a session variable to allow loading the Javascript page at the
top of the page and have it reset after the page has loaded. One cannot
simply reset it at the end using PHP code embedded in the (PHP parsed) raw
HTML page itself because it would be reset when the HTML page is first
parsed by the PHP engine, before it is even sent out and before the
Javascript has had a chance to load, not after it has loaded, so one has to
have something accessed after the Javascript has been loaded and have the
PHP engine reset the accessibility variable when that item is accessed.

These are PHP session variables and not Javascript. They enable stateful
data to be used for a web session. They can and are used for lots of things.

The code at http://code.google.com/p/turbojs/wiki/ClosedSourceJS uses a PHP
session variable (the key or property of the $_SESSION associative
array/object, 'js_turbo01') as the Javascript accessibility variable. The
first thing the sample shows is the command to have the webserver *not*
simply send a visitor's browser a *.js file but instead pass it along to the
PHP engine to parse it and return the results presented by the php engine
AddType application/x-httpd-php .js

At the start of the "proper page" which uses the Javascript, the
accessibility variable is set ("show" is the value used to indicate it is
set to allow access) and at the end of the page an item to unset the
accessibility variable (when it is accessed and parsed by the PHP engine) is
added (the "dummy.js" file in the sample at
http://code.google.com/p/turbojs/wiki/ClosedSourceJS).

When one tries to access the "protected" code, closedsource.js, in the
example, the raw original file is not returned but it is passed along to the
PHP engine which checks the state (is access allowed?) and if so it returns
the real code and if not it may return something else (in the sample shown,
it just returns text indicating an error but the PROTIP at the bottom
suggests returning code different from the "real" code when accessed without
the accessibility variable properly set).

Oct 24 '08 #23

Spamless

On 2008-10-24, Thomas 'PointedEars' Lahn <Po*********@web.dewrote:

Incidentally, you can find Firebug, which among other things allows you to
get the source code without further request in Firefox, there, too:

<http://code.google.com/p/fbug/>

How well does it work? Have you seen (I have) javascript which deletes
itself from the page (or other Javascript)? It runs some code then looks
for script elements and ... uses the DOM to remove them. I've seen that a
time or two in exploit scripts (whose authors really don't want you to see
what is going on). Will firebug show the code which was on the page?

Oct 25 '08 #24

Conrad Lender

On 2008-10-25 02:37, Spamless wrote:

How well does it work? Have you seen (I have) javascript which
deletes itself from the page (or other Javascript)? It runs some code
then looks for script elements and ... uses the DOM to remove them.
I've seen that a time or two in exploit scripts (whose authors really
don't want you to see what is going on). Will firebug show the code
which was on the page?

Yes.
http://groups.google.com/group/comp....5f059ad2b00e20
- Conrad

Oct 25 '08 #25

Spamless

On 2008-10-25, Conrad Lender <cr******@yahoo.comwrote:

On 2008-10-25 02:37, Spamless wrote:
>How well does it work? Have you seen (I have) javascript which
deletes itself from the page (or other Javascript)? It runs some code
then looks for script elements and ... uses the DOM to remove them.
I've seen that a time or two in exploit scripts (whose authors really
don't want you to see what is going on). Will firebug show the code
which was on the page?

Yes.
http://groups.google.com/group/comp....5f059ad2b00e20

I think no.

It leaves a reference but does not show the code.

With an HTML page,

<html><head></head><body onload="goaway()">
<script src=go.js></script>
All gone!
</body></html>

and a javascript file, go.js

function goaway() {
alert("Be GONE!");
}
loading the page and then running firebug to examine it shows the
source and even the code from the loaded Javascript file
(there is a "+" sign next to the
<body onload="goaway()">
section which can be used to expand it and find the
the <script src=go.js></scriptinclusion which can
be expanded to show the source creating the alert box).
Changing go.js to

function goaway() {
alert("Be GONE!");
togo=document.body.childNodes[1];
document.body.removeChild(togo);
}
and reloading the page removes
<script src=go.js></script>
from the DOM (as one can see by using the DOM tool
(TOOLS|DOM_INSPECTOR).

That is now gone (the + sign next to the <bodytag
is gone - no expansion to find the source file or
the code creating the alert box).

Actually, opening firebug FIRST and loading the page
apparently shows the code (while the alert box is on
screen and before the javascript section is removed from
the page) (the plus sign next to the body tag is there
for me to expand to show the code - if I could, but the
alert box is modal and I can't expand it to see the code
until I close the alert box) but as soon as I close the
alert box, the plus sign indicating that I can get to
the javascript code disappears and the code is not
available. Perhaps you get a different result and firebug
does show you the javascript for the alert box for
the second version of go.js.

Oct 25 '08 #26

Gregor Kofler

Spamless meinte:

[lenghty explanation snipped]

You never see the raw index.html *file* with its embedded PHP code but only
the HTML code that the PHP engine produces *from* the raw html code and that
returned HTML code depends on the current state/session data. This is all
done server side and the visitor does not see the server-side state data
which determines which page he/she gets.

So what? That's the case with practically any PHP "page" (or any by a
server-side script generated page for that matter).

[snip]

It's all very simple and "standard": One can prevent to get direct
access to the ressources on the server (dynamically generating images -
think CAPTCHA, PDFs in "hidden" directories, etc.). However, once it is
delivered to the client, it's there. Fully inspectable. So what's this
whole discussion about?

Gregor

Oct 25 '08 #27

Gregor Kofler

Spamless meinte:

With an HTML page,

<html><head></head><body onload="goaway()">
<script src=go.js></script>
All gone!
</body></html>

function goaway() {
alert("Be GONE!");
togo=document.body.childNodes[1];
document.body.removeChild(togo);
}

Actually, opening firebug FIRST and loading the page
apparently shows the code (while the alert box is on
screen and before the javascript section is removed from
the page) (the plus sign next to the body tag is there
for me to expand to show the code - if I could, but the
alert box is modal and I can't expand it to see the code
until I close the alert box) but as soon as I close the
alert box, the plus sign indicating that I can get to
the javascript code disappears and the code is not
available. Perhaps you get a different result and firebug
does show you the javascript for the alert box for
the second version of go.js.

Have a breakpoint at the first line of goaway() and reload the page. Doh!

Gregor

Oct 25 '08 #28

Spamless

On 2008-10-25, Gregor Kofler <us****@gregorkofler.atwrote:

Spamless meinte:

[lenghty explanation snipped]

>You never see the raw index.html *file* with its embedded PHP code but only
the HTML code that the PHP engine produces *from* the raw html code and that
returned HTML code depends on the current state/session data. This is all
done server side and the visitor does not see the server-side state data
which determines which page he/she gets.

So what? That's the case with practically any PHP "page" (or any by a
server-side script generated page for that matter).

True, but this is a Javascript group and at least the person who saw the
original file knew some Javascript but apparently did not recognize how the
embedded PHP code works. It was intended to be an elementary explanation.

The closedsource code presented at
http://code.google.com/p/turbojs/wiki/ClosedSourceJS
was simply to prevent one from getting the *.js file except when the "proper
page" is loaded, to prevent someone from just harvesting *.js files (and if
they try, to be able to give them bogus script and they may not realize that
it isn't the real code used).

Of course the script does load, when you load the proper page (else it would
be pointless) and you do have it - somewhere - in your browser's cache, for
example though the "[script src ...]" might have been removed from the page
using the DOM and does not appear in firebug so you don't have the file name
- but ... in firefox, View|Page_Source still shows that inclusion and the
file name for searching the cache.

Tell someone that the ineteresting script is at
http://someplace.com/interesting.js
and they attempt to get it without knowing a page URL which can/must be used
actually to get the code and they may find a totally different script.

If you know that you have to load a particular HTML page to get a particular
script, you can load the HTML page to get the script (or have to load a
particular image or have seen a particular ad or ...) you can do it. It does
put limits (of which the remove visitor is unaware) on how/when a particular
script can be accessed.

Oct 25 '08 #29

Santander

So it possible to delete javascript code from page after script has been
executed? That's very intersting, so it possible hide code all the same.
Could you show html page example that use this approach?

Santander

-------------
"Spamless" <Sp******@Nil.nilwrote in message
news:49***********************@news.thorn.net...

How well does it work? Have you seen (I have) javascript which deletes
itself from the page (or other Javascript)? It runs some code then looks
for script elements and ... uses the DOM to remove them. I've seen that a
time or two in exploit scripts (whose authors really don't want you to see
what is going on). Will firebug show the code which was on the page?

Oct 25 '08 #30

Gregor Kofler

Santander meinte:

So it possible to delete javascript code from page after script has been
executed?

Yes. "Jorge" started a thread in this NG 7 days ago.

That's very intersting, so it possible hide code all the same.

No. Not if somebody is determined to get the code. Hasn't this become
clear, yet?

Gregor

Oct 25 '08 #31

David Mark

On Oct 24, 11:59*pm, Spamless <Spaml...@Nil.nilwrote:

On 2008-10-25, Conrad Lender <crlen...@yahoo.comwrote:

On 2008-10-25 02:37, Spamless wrote:
How well does it work? Have you seen (I have) javascript which
deletes itself from the page (or other Javascript)? It runs some code
then looks for script elements and ... uses the DOM to remove them.
I've seen that a time or two in exploit scripts (whose authors really
don't want you to see what is going on). Will firebug show the code
which was on the page?

Yes.
http://groups.google.com/group/comp....5f059ad2b00e20

I think no.

You don't have to think as several posters have told you why you are
wrong.

>
It leaves a reference but does not show the code.

Meaningless.

>
With an HTML page,

<html><head></head><body onload="goaway()">
<script src=go.js></script>
All gone!
</body></html>

and a javascript file, go.js

function goaway() {
* alert("Be GONE!");

}

loading the page and then running firebug to examine it shows the
source and even the code from the loaded Javascript file
(there is a "+" sign next to the
* *<body onload="goaway()">
section which can be used to expand it and find the
the <script src=go.js></scriptinclusion which can
be expanded to show the source creating the alert box).

And?

>
Changing go.js to

function goaway() {
* alert("Be GONE!");
* togo=document.body.childNodes[1];
* document.body.removeChild(togo);

}

and reloading the page removes
* <script src=go.js></script>
from the DOM (as one can see by using the DOM tool
(TOOLS|DOM_INSPECTOR).

You don't even have a glimpse of a clue here. Go back and re-read the
previous posts in this thread (excluding the ones you wrote.)

[snip]

Oct 26 '08 #32

Spamless

On 2008-10-26, David Mark <dm***********@gmail.comwrote:

>>
and reloading the page removes
=A0 <script src=3Dgo.js></script>
from the DOM (as one can see by using the DOM tool
(TOOLS|DOM_INSPECTOR).

You don't even have a glimpse of a clue here. Go back and re-read the
previous posts in this thread (excluding the ones you wrote.)

I don't have a glimpse of a clue there? It is not removed?
Oh, but it is removed from the HTML. The use of local variables
wrapped in an anonyous function and the removal of the material from
the HTML page removes all references from firebug's DOM panel.
Those are details of which I am sure you are aware (or should be).
But of course that is nonsense and I am clueless. They could not
be removed, for you say so.
However, I did err due to an apparent difference in the handling
of local vs. remote files in firebug's SCRIPTS panel. By the way,
in rereading all the prior messages I have seen no one comment
on this. Alas.
With an HTML page,

[a.html]
--------
<html><head></head><body onload="goaway()">
<script src=go.js></script>
All gone!
</body></html>

loading

[go.js]
-------
function goaway() {
alert("Be GONE!");
var togo=document.body.childNodes[1];
document.body.removeChild(togo);
document.body.removeAttribute("onload");
goaway=null;
onload=null;
}
The HTML panel of firebug surely shows the script gone.
The DOM tool shows the global Javascript functions
onload and goaway, but they are null and not clickable.

I am sure you are aware of this having tested it so
thoroughly.
The SCRIPT panel of firebug shows the page source and
has a drop down list allowing one to see the contents
of go.js. Before using that, I changed (on my local
copy) "Be GONE!" to "Be GENE!" and used it. The script
panel, in showing go.js apparently loaded it again directly
(it showed "Be GENE!") (and of course, that is what the code
at google is designed to foil - another separate load of
the script file). Of course, that google posted code cannot
work - for you said so. After all it only requires, as you
said, but ONE connection to the web server to get the
material, not one to set the accessibility and another to
get the script file (and then access is blocked).
I am sure you are aware of all this having tested it so
thoroughly.
HOWEVER, putting the files on a REMOTE server and using
the SCRIPT panel (and its drop down list) shows the go.js
file, but running a packet capture shows that it did NOT
reload the file (and did not send a query to see if it
had changed). I short, the SCRIPT tab apparently shows
the javascript as obtained in its first download.

By the way, what packet capture programme did you run when
you tested this?
Since you surely were aware of the differences in handling
local and remote files and the fact that, for example,
using anonymous global functions (with no name to be used)
wrapping all local variables and removing the material from
the HTML of the page would definitely remove all references
to all the Javascript both from the HTML panel and the DOM
panel but would leave access to the material in the SCRIPTS
panel which treats local and remote files differently, it
appears.
Surely you did check before saying "NONSENSE" and "CLUELESS"
but I wish you had given some details about your results
instead of simply saying "NONSENSE" and "CLUELESS" sufficiently
many times to make them true.
What *were* the results of your tests and what code did you use?

Oct 26 '08 #33

Spamless

On 2008-10-26, Spamless <Sp******@Nil.nilwrote:

The SCRIPT panel of firebug shows the page source and
has a drop down list allowing one to see the contents
of go.js. Before using that, I changed (on my local
copy) "Be GONE!" to "Be GENE!" and used it. The script
panel, in showing go.js apparently loaded it again directly
(it showed "Be GENE!")

HOWEVER, putting the files on a REMOTE server and using
the SCRIPT panel (and its drop down list) shows the go.js
file, but running a packet capture shows that it did NOT
reload the file (and did not send a query to see if it
had changed). I short, the SCRIPT tab apparently shows
the javascript as obtained in its first download.

Let me check your expertise. The above is true. Why?
And have you tested your explanation?

Oct 27 '08 #34

Spamless

Rats. Firebug makes it easy to search the cache for the original
download of the script.

On 2008-10-26, Spamless <Sp******@Nil.nilwrote:

In firebug, in the DOM view (the default is also to show user defined
functions and Javascript variables) of the document one finds a reference to
go.js (why? because of "togo" - see below) and one can right click that and
choose to inspect it in the HTML window to find it and see the code BUT
apparently[*] it goes and reloads it to display it (as it is gone from the
document). Part of this thread shows a PHP block which prevents one from
getting a script except when loading the page it is on.

*: After loading the page, I renamed go.js and then tried to use firebug to
show it in the HTML panel and this time it failed. ...

....

Of course, if you see the source code and the load of go.js, it is in your
browser's cache and can still be found.

But firebug makes it easy to find the file in cache.
All the above is true, since I used "apparently."

For remote files, firebug does not go get it again.
Why the difference between my first test (when it first tested
it I was using local files) and for remote files?

Firefox does not cache loads of local files. Why should it? The files
are right there, easily loaded again.

The SCRIPTs panel in firebug has a drop down list of files loaded
for the current page. It is a search tool to locate the data in
firefox's cache. For local files, not saved in cache, firebug had
to reload the local file. For remote files, it finds them in the
browser's cache and loads from there (so you see original downloaded
versions). Loaded from cache and not from the browser's memory?
Loading a file from a remote server, checking the access time of the
copy in firefox's cache, waiting a minute or so and then using the
SCRIPT's panel's drop down list to show the contents of go.js and
checking the access time again of the cached copy showed that it had
just been read/accessed.).
So, the above is true (you can remove and block references in firebug's
HTML and DOM panels by removing the javascript node and using local
variables wrapped in an anonymous function) but you have the copies
in the brower's cache. Firebug has a cache access tool to find and
display those cached copies and makes them easily accessible (both
the original HTML page and javascript code it loaded).

Oct 27 '08 #35

Conrad Lender

On 2008-10-27 02:20, Spamless wrote:

Rats. Firebug makes it easy to search the cache for the original
download of the script.

Why are you still trying to make this work? You're trying to trick the
GUI of an add-on in one particular browser. And you *know* that anybody
with a rudimentary understanding of the web can just pick the file
contents from the HTTP stream (you mentioned packet sniffers yourself).

Some things just can't be done. There's no shame in admitting defeat
against the impossible. I've only ever found _one_ reliable way to keep
people from copying scripts: write crappy scripts :-)
- Conrad

Oct 27 '08 #36

Lasse Reichstein Nielsen

Conrad Lender <cr******@yahoo.comwrites:

I've only ever found _one_ reliable way to keep
people from copying scripts: write crappy scripts :-)

Looking at the web today, I'd say that strategy is doomed to fail too :)
/L
--
Lasse Reichstein Holst Nielsen
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

Oct 27 '08 #37

Gregor Kofler

Conrad Lender meinte:

Some things just can't be done. There's no shame in admitting defeat
against the impossible. I've only ever found _one_ reliable way to keep
people from copying scripts: write crappy scripts :-)

Doesn't work, too. In fact, the crappier the script, the more it will
spread...

Gregor

Oct 27 '08 #38

Spamless

On 2008-10-27, Conrad Lender <cr******@yahoo.comwrote:

On 2008-10-27 02:20, Spamless wrote:
>Rats. Firebug makes it easy to search the cache for the original
download of the script.

Why are you still trying to make this work? You're trying to trick the
GUI of an add-on in one particular browser. And you *know* that anybody
with a rudimentary understanding of the web can just pick the file
contents from the HTTP stream (you mentioned packet sniffers yourself).

I wanted to know just how far one could push fooling firebug (since
others seem to rely heavily on it) and *if* it could be fooled
completely and if not, what to watch out for - which tools *can*
be fooled and which can't, and why.

Some things just can't be done.

But why can't it be done. I am a mathematician and need proofs.

There's no shame in admitting defeat against the impossible. I've only
ever found _one_ reliable way to keep people from copying scripts: write
crappy scripts :-)

It is a trick. It makes it difficult for the unwary even to realize that
something has happened (that there *was* code on a page when the "live"
panels in firebug, HTML and DOM, no longer show it - if you forget to
check the cache via the SCRIPT panel you may miss something).

It's just a trick. You and I can get around it. I just want to know
enough of what can be done so that, if I come across it (and I have
come across exploit pages which remove Javascript) I will recognize
it and not be fooled. Don't rely on the HTML and DOM view in firebug
which are live and be fooled by removing data from a page (and avoiding
leaving global Javascript variables and non-anonymous functions around
which the DOM view can show).

Until I was sure how the SCRIPT panel in firebug works (it seems
to be a cache access tool - and the file WILL BE in cache) I didn't
*know* for a fact whether or not firebug could be completely fooled.
As data is in the cache, and firebug has a tool to search and
access that, that tool cannot be fooled. The live tools can.

By the way, did you realize that SCRIPT seems to be a cache access
tool and why about:cache in firefox and clicking on an item there
may not show the cached data? It sends a request to the original
source only asking for a more recent value (an "If-Modified-Since:"
header). It may return newer, not cached data. That may not be a
reliable way to check cached data (onless one is offline to force
a cached value to be used?).

A litle detail - but I like to know how things work in depth.

Ah, heck ... this is a Javascript forum. The original question was
just about deobfuscating some (simply) obfuscated code. That led
to a reference to a google page and the poster did not know how
the Javascript there worked - but it was a PHP blocker. That led
to the question of how to find things on a page. That led to using
firebug. That led to questions as to what it shows and can one
fool (at least parts of) it.

Oct 27 '08 #39

Gregor Kofler

Spamless meinte:

>Some things just can't be done.

But why can't it be done. I am a mathematician and need proofs.

You're a mathematician? Then you know what an axiom is.

Gregor

Oct 27 '08 #40

Conrad Lender

On 2008-10-27 09:41, Spamless wrote:

>Some things just can't be done.

But why can't it be done. I am a mathematician and need proofs.

I'm not a mathematician. I can't even read moderately complex
mathematical proofs (I've tried, but the notation alone is enough to fry
my brain), so I'll settle for common sense:

In the end, the scripting engine has to see the raw source code.
Whatever you do, there must be a way for a HTTP user agent to read (and,
if necessary, decode) your secret message (ie, the hidden script). What
a UA can do, an attacker can do as well. It may be *complicated*, but
the UA itself is proof that it *can* be done.

>There's no shame in admitting defeat against the impossible. I've only
ever found _one_ reliable way to keep people from copying scripts: write
crappy scripts :-)

....

It's just a trick. You and I can get around it. I just want to know
enough of what can be done so that, if I come across it (and I have
come across exploit pages which remove Javascript) I will recognize
it and not be fooled.

From that point of view, it's indeed an interesting question. I've been
working with a network security person from time to time, and from what
I hear, JS exploits have become a lot more common and more sophisticated
over the last years. Since the Web 2.0 thing took off, people are also
less likely to disable scripting than before.

I consider it part of my job to be able to spot what's going on, and
your tests with Firebug were actually quite interesting (_and_ on topic
here, as far as I'm concerned). It just seemed to me that you were
approaching this from the opposite side ("Rats, I couldn't fool Firebug"
instead of "Hehe, they couldn't fool Firebug").

By the way, did you realize that SCRIPT seems to be a cache access
tool and why about:cache in firefox and clicking on an item there
may not show the cached data? It sends a request to the original
source only asking for a more recent value (an "If-Modified-Since:"
header). It may return newer, not cached data.

Same thing happens with "view source". It will (sometimes) send a new
request, but *without* the cookies, and instead of the source of the
page you're interested in, you'll see the source of the login form :-/
Firebug is one way to work around that.
- Conrad

Oct 27 '08 #41

Spamless

On 2008-10-27, Conrad Lender <cr******@yahoo.comwrote:

On 2008-10-27 09:41, Spamless wrote:

>By the way, did you realize that SCRIPT seems to be a cache access
tool and why about:cache in firefox and clicking on an item there
may not show the cached data? It sends a request to the original
source only asking for a more recent value (an "If-Modified-Since:"
header). It may return newer, not cached data.

Checking at mozilla/firefox all the information on browsing the cache
seems to be "use about:cache" (no mention of forcing it NOT to load
material with Work Offline).

Same thing happens with "view source". It will (sometimes) send a new
request, but *without* the cookies, and instead of the source of the
page you're interested in, you'll see the source of the login form :-/
Firebug is one way to work around that.

Or, in firefox, FILE|WORK_OFFLINE?

(and I remember one spammer who put up a new site and did not set
*.php files to be run through the PHP engine - so accessing the
index.php file showed its source and inclusions of other *.php
files which showed ...)

Oct 27 '08 #42

David Mark

On Oct 26, 7:37*pm, Spamless <Spaml...@Nil.nilwrote:

On 2008-10-26, David Mark <dmark.cins...@gmail.comwrote:

and reloading the page removes
=A0 <script src=3Dgo.js></script>
from the DOM (as one can see by using the DOM tool
(TOOLS|DOM_INSPECTOR).

You don't even have a glimpse of a clue here. *Go back and re-read the
previous posts in this thread (excluding the ones you wrote.)

I don't have a glimpse of a clue there? It is not removed?

By "there" I mean any subject with even a remote connection to browser
scripting, debugging, browsers in general, Firefox specifically, etc.

Your misconceptions have been described repeatedly in this thread. Re-
read it from the start. Then realize that if you don't want people to
see your script, you shouldn't post it on a public Web server. End of
story.

Oh, but it is removed from the HTML. The use of local variables

Best of luck hiding your script. It must be really good to go to all
of this trouble.

Oct 28 '08 #43

Similar topics